Home A - Z
Page Index

An Otter Wiki

Tracking Plan Changes — Annotated Gantt Charts and Project Logs

The two instruments C10-3 is marked from, and the meta-log that turns them into a judgement. Read it before class write 3.

Note

The bands this serves. C10-3, 3–4: annotations outline the modifications. 5–6: annotations describe them. 7–8: adjustments or logs/journals document and explain them. 9–10: evaluates the modifications. Each rung adds something — an annotation that only says what changed cannot reach 7–8, and no amount of logging reaches 9–10 without a verdict.

flowchart LR
    G["Annotated Gantt<br/>baseline vs actual"] --> M
    E1["Log entry<br/>date · what changed · why<br/>impact · who decided · evidence"] --> M
    E2["Log entry"] --> M
    E3["Log entry"] --> M
    M["The meta log — your final entry<br/>What pattern of changes?<br/>Reactive or proactive?<br/>Did they help or harm?"] --> C4["C10-4<br/>plan effectiveness"]

Everything funnels into one entry. The individual logs are evidence; the meta-log is the judgement, and it is also what C10-4 draws on.

What is this?

By reviewing how and why your plan changed, you gain evidence of adaptability and critical decision-making—not just task tracking.

Purpose: Document project modifications with reflective analysis for C10-3 assessment.

🎯 Choose Your Tracking Method

Option 1: Traditional Approach

  • 📊 1. Annotated Gantt Chart
  • 📝 2. Project Log File

Option 2: GitHub Approach

  • 📊 1. GitHub Projects (Gantt view)
  • 📝 2. GitHub Issues (tracking)

📊 Annotated Gantt Chart Guide

What to Show:

  • 🔹 Original timeline (from Unit 3) vs actual timeline
  • 🔹 Task modifications: Added, removed, or changed tasks
  • 🔹 Duration changes: Tasks that took longer/shorter than planned
  • 🔹 Milestone shifts: Deadlines that moved
  • 🔹 Resource adjustments: When you needed help or changed priorities

How to Annotate:

Traditional Method (GanttProject/Excel):

Annotation Examples:  
• "Extended coding by 3 days - alpha testing revealed more bugs"  
• "Added validation task - requirements changed after client feedback"  • "Moved documentation earlier - needed for beta testing prep"  
• "Reduced UI design time - focused on functionality first"

GitHub Projects Method:

  • Use milestone descriptions to explain changes
  • Add timeline comments on project board
  • Use labels to categorise change types (scope, technical, timeline)
  • Project notes explain major modifications

📝 Project Logs Guide

What to Track:

  • 🔹 Date and time of each change
  • 🔹 What changed (task, deadline, scope, resources)
  • 🔹 Why it changed (testing results, technical issues, feedback)
  • 🔹 Impact (how it affected other tasks)
  • 🔹 Decision maker (you, teacher feedback, user input)

Log Categories:

  • Scope changes: New/removed features - Did this add value or cause delay?
  • Timeline adjustments: Extended/compressed tasks - Did this make the project finish earlier/later? - Technical issues: Bug fixes, tool problems - Did this improve solution quality?
  • Resource changes: Help needed, priority shifts - Did this make development more efficient?
  • User feedback: Changes from testing - Did this better meet user needs?
  • AI assistance: When AI tools helped/hindered development progress - Did this speed up or complicate development?

💭 Add Reflection Checkpoints:

After major milestones (alpha testing, beta testing, major feature completion), write 1-2 reflective sentences:

  • "After alpha testing, I realized my original timeline was too optimistic for validation work"
  • "Beta feedback showed users needed simpler navigation - good thing I built this modularly"

📸 Include Evidence Annotations:

For 2-3 key log entries, add supporting evidence:

  • Screenshot: Before/after interface changes
  • Code snippet: Key bug fix or improvement
  • Timeline visual: Gantt chart section showing the change
  • Caption: "This validation fix prevented major user errors"

Option 1: Traditional Log File

Simple Log Template:

WEEK 4 REVIEW (Post-Alpha Testing):  
DATE: 2025-08-12  
CHANGE: Extended coding phase by 2 days  
REASON: Alpha testing found validation errors  
IMPACT: Beta testing delayed by 1 day, but solution quality improved  
DECISION: Worth the delay to fix critical bugs  
EVIDENCE: [Link to testing results, commit #a3b2c1]  
REFLECTION: Original timeline was too optimistic for validation work  
  
WEEK 6 REVIEW (Post-Beta Testing):  
DATE: 2025-08-18  CHANGE: Added user tutorial feature  
REASON: Beta testers confused by interface  
IMPACT: Extra 3 days development, but much better usability scores  
DECISION: Essential for user adoption  
EVIDENCE: [Screenshots of old vs new interface]  
REFLECTION: Should have planned for user guidance from the start

Option 2: GitHub Issues Method

Issue Structure:

Title: [TIMELINE] Extended coding phase  
Labels: timeline-change, technical-issue  
Milestone: Week 5 Development  
  
Description:  
**What Changed:** Coding phase extended by 2 days  
**Reason:** Alpha testing revealed validation errors  
**Impact:** Beta testing timeline pushed back  
**Status:** Resolved - bugs fixed, back on track  
  
**Evidence:** - Link to testing results  
- Commit hash of bug fixes  
- Updated project timeline

GitHub Projects Benefits:

  • Visual project board with timeline and status tracking
  • Issue linking to commits and evidence
  • Real-world project management practice

⚠️ Don't Forget the Meta Log:

Final log entry (C10-3-9): Evaluate all modifications you made to your initial project plan.

Meta-Reflection Questions:

  • What pattern of changes occurred? (Mostly scope creep? Technical challenges? Good adjustments?)
  • Were changes reactive (fixing problems) or proactive (improving quality)?
  • Did modifications improve or harm project success?
  • What does this tell you about your original planning?

This meta-analysis becomes crucial evidence for C10-4 effectiveness assessment.

📋 Documentation Checklist

For C10-3 Assessment, Include:

  • 🔲 Original plan (baseline for comparison)
  • 🔲 All modifications documented with dates
  • 🔲 Reasons for changes clearly explained
  • 🔲 Impact analysis (how changes affected other tasks)
  • 🔲 Change categories (scope, timeline, technical, resources)
  • 🔲 Resolution status (how issues were resolved)

✨ Pro-tips:

Document as you go - Don't try to recreate logs at the end
Be specific - "Testing revealed bugs" vs "Alpha testing found 3 validation errors in user input"
Show impact - Explain how each change affected the bigger picture
Use timestamps - Real dates and times show authentic tracking
Link evidence - Connect logs to actual project artifacts (commits, tests, etc.)

🎯 Remember:

C10-4 will use this tracking data to assess your plan's effectiveness, so detailed logs = better C10-4 reflection!

Check Your Understanding

1. Which band does this log entry reach, and what would lift it one rung? "Week 4: extended coding by 2 days."

Answer

Band 3–4 — it outlines the modification and nothing else. Adding why and its impact ("alpha testing found three input-validation errors; beta testing slipped a day but the build was stable") moves it into explanation, which is the 7–8 territory.

2. Why does the guide insist on real dates and timestamps rather than tidy round numbers?

Answer

Because the record has to be authentic, and your teacher reads commit dates from the server. A log reconstructed at the end contradicts the commit history it claims to describe.

3. What separates the meta-log from the entries above it?

Answer

The entries record; the meta-log judges. It looks across all the changes for a pattern — mostly scope creep? mostly technical? reactive or proactive? — and says whether the modifications helped or harmed the project.